087354-0108 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Applicant: Charles BERNASCONI et al. 

Title: NOTIFICATION OF 

EMPLOYEES VIA PASS 
CODE ACCESSED WEB 
PAGES 

09/641,866 

08/18/2000 

Kristine K. Rapillo 

3626 

7547 



Appl. No.: 

Filing Date: 

Examiner: 

Art Unit: 

Confirmation 
Number: 



Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 



DECLARATION OF MR. ROLAND THOMPSON 



Dear Sir: 



I, the undersigned Roland Thompson, an American citizen with an office at 5 
Great Valley Parkway, Malvern, Pennsylvania, USA, hereby declare and state that: 



WASH_5408271.1 
WASH 6195029.1 



087354-0108 



Background 

1 . I am a co-founder of the company Frontline Placement Technologies, Inc. 
(hereafter "Frontline"), and currently serve as a Managing Partner for the company. Frontline is 
the assignee for the present application. 

2. Michael Blackstone and I conceived of the idea of a Web based substitute 
fulfillment system and founded Frontline Data, Inc., later renamed Frontline Placement 
Technologies, Inc., in 1 998. We now have 65 employees, and provide substitute fulfillment 
services for over 1700 school districts in 47 states. We also provide shift fulfillment for 
manufacturing operations for a number of companies using Web fulfillment. I was the concept 
designer for the software for the automated substitute fulfillment system for Frontline Placement 
Technologies, Inc. 

3. In 1996 I co-founded Thompson & Blackstone, Inc., a technical services and 
business company thinktank. 

4. I was the co-founder and CEO of CF InFlight, LLP, which introduced Skycam 
(www.skycam.tv) to the sports broadcasting world. As the chief designer of the software for 
Skycam and chief executive, I brought Skycam to its present status, where it is featured on many 
of the worlds premier sports broadcasts including ESPN NFL broadcasts and several Super 
Bowls. 

5. Prior to these ventures, I spent 1 0 years building an information technology 
services organization, Cone Software, focused on delivering IT services and software for stock 
and currency trading applications and developing mobile technology solutions for Fortune 500 
companies. In that company, I designed and supervised the design of software for multiple 
platforms and for multiple applications. 

6. I received a B.S. degree in computer science from West Chester University of 
Pennsylvania. 
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7. I am familiar with the claims and specification of the present patent application. 

Meaning of the term "immediate response" and "immediately removing" in the Claim 
Element: 

the one or more computers configured for automatically 
assigning the new open position only to one of the one or more 
preferred workers during a specified time period, in immediate 
response to receipt of an electronic selection of the new open 
position from one of the one or more preferred workers and 
immediately removing the position as an available for selection 
open position; 

the one or more computers configured for assigning the 
new open position, after the expiration of the specified time period, 
to one of the qualified workers for which the new open position is 
made available for selection in immediate response to receipt of an 
electronic selection of the new open position from that qualified 
worker. 



8. One of ordinary skill in the information technology art would understand that the 
use of the word "immediate response" in the above-recited claim element means that the system, 
comprising the one or more computers, starts a transaction to fulfill the position on receipt of the 
acceptance. The transaction may comprise, as one of ordinary skill would be aware, multiple 
different operations including one or more accesses to a database. No other worker acceptance 
subsequently received can jump ahead or override this transaction. In this respect, see the 
discussion of the term transaction in the "Sybase SQL Server Transact-SQL User's Guide," 
Release 1 1 .0, lasted revised December 15, 1995, which is attached as an Exhibit to this 
Declaration. Note that this does not require that the posting on the respective web pages 
immediately be removed. But it does mean that it is no longer possible for another worker to 
accept the position. This would be clear to one or ordinary skill in the art. 

9. I hereby declare that all statements made herein, unless otherwise indicated, are of 
my own knowledge and are true, and that all statements made on information and belief are 
believed to be true; and further that these statements were made with the knowledge that willful 
false statements and the like so made are punishable by fine or imprisonment, or both, under 18 
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U.S.C. § 1001, and that such willful false statements can jeopardize the validity of any patent 
issuing from the captioned application or claiming the benefit of its priority. 




Dated: / / ^ / , 2009 

Malvern, PA 



Signed by: 




Roland Thompson 
/fjrt00M& /#s/6c/~ \ Frontline Placement Technologies, Inc. 
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Transactions: Maintaining Data 
Consistency and Recovery 

Transactions provide a way to group Transact-SQL statements so 
that they are treated as a unit. Either all statements in the group are 
executed or no statements are executed. 

This chapter discusses: 

• An overview of transactions 

• How to use group statements in a transaction 

• How to define transaction modes and isolation levels 

• How stored procedures and triggers work with transactions 

• How cursors work with transactions 

• Backup and recovery of transactions 

What Are Transactions? 



A transaction is a mechanism for ensuring that a set of one or more 
SQL statements is treated as a single unit of work. SQL Server 
automatically manages all data modification commands, including 
single-step change requests, as transactions. By default, each insert, 
update, and delete statement is considered a single transaction. 

You can group a set of SQL statements into a user-defined 
transaction with the begin transaction, commit transaction, and rollback 
transaction commands, begin transaction marks the beginning of a 
transaction block. All subsequent statements, up to a rollback 
transaction or a matching commit transaction, are included as part of the 
transaction. 

Transactions allow SQL Server to guarantee: 

• Consistency - Simultaneous queries and change requests cannot 
collide with each other, and users never see or operate on data 
that is part way through a change. 

• Recovery - In case of system failure, database recovery is 
complete and automatic. 

To support SQL standards-compliant transactions, SQL Server 
provides options that allow you to select the mode and isolation level 
for your transactions. Applications that require SQL standards- 
compliant transactions should set those options at the beginning of 
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every session. Transaction modes and isolation levels are described 
later in this chapter. 

Transactions and Consistency 

In a multiuser environment, SQL Server must prevent simultaneous 
queries and data modification requests from interfering with each 
other. This is important because if the data being processed by a 
query could be changed by another user 's update while the query 
runs, the results of the query would be ambiguous. 

SQL Server automatically sets the appropriate level of locking for 
each transaction. You can make shared locks more restrictive on a 
query-by -query basis by including the holdlock keyword in a select 
statement. 

User-defined transactions allow users to instruct SQL Server to 
process any number of SQL statements as a single unit. They are 
discussed in a later section. 



Transactions and Recovery 

A transaction is both a unit of work and a unit of recovery. The fact 
that SQL Server handles single-step change requests as transactions 
means that the database can be recovered completely in case of 
failures. 

SQL Server's recovery time is measured in seconds and minutes. You 
can specify the maximum acceptable recovery time. 

The SQL commands related to recovery and backup are discussed in 
''Backup and Recovery of Transactions" on page 17-21. 

Using Transactions 

begin transaction and commit transaction tell SQL Server to process any 
number of single commands as a single unit, rollback transaction 

undoes the transaction, either back to its beginning, or back to a 
savepoint. You define a savepoint inside a transaction with the save 
transaction command. 

User-defined transactions give you control over transaction 
management. They also improve performance, since system 
overhead is incurred once per transaction, rather than once for each 
individual command. 
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► Note m w — 

Grouping large numbers of Transact-SQL commands into one long-running 
transaction may affect recovery time. If SQL Server fails before the 
transaction commits, recovery is longer, because SQL Server must undo 
the transaction. 



Any user can define a transaction. No permission is required for any 
of the transaction commands. 

The following sections discuss general transaction topics and 
transaction commands, with examples. For more information about 
transactions, see the SQL Server Reference Manual 

Allowing Data Definition Commands in Transactions 

You can use certain data definition language commands in 
transactions by setting sp_dboption s ddJ in tran option to true. If ddl in tran 
is true in a particular database, you can issue commands such as 
create table, grant, and alter table inside transactions in that database. If 
ddl in tran is true in the model database, you can issue the commands 
inside transactions in all databases created after ddl in tran was set to 
true in model 

♦ WARNING! — — ™ ™ ™ ™™- ™ - ■ ■ 

The only scenario in which using data definition language commands 

inside transactions is justified is in create schema. Data definition 
language commands hold locks on system tables such as sysobjects. 
If you use data definition language commands inside transactions, 
keep the transactions short. 

In particular, avoid using any data definition language commands on 
tempdb within transactions, lest your system grind to a halt. Always 
leave ddl in tran set to false in tempdb. 



To set ddl in tran to true, type: 

sp_ciboption mydb, "ddl in tran", true 

The first parameter specifies the name of the database in which to set 

the option. You must be using the master database to execute 

sp dboption. Any user can execute sp dboption with no parameters to 
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display the current option settings. To set options, however, you 
must be either a System Administrator or the Database Owner. 

The following commands are allowed inside a user-defined 
transaction only if the ddi in tran option to sp_dboption is set to true: 



Table 17-1: DDL commands allowed in transactions 



alter table 


create default 


drop default 


grant 


(clauses other 


create index 


drop index 


revoke 


than partition 


create procedure 


drop procedure 




and unpartition 


create rule 


drop rule 




are allowed) 


create schema 


drop table 






create table 


drop trigger 






create trigger 


drop view 






create view 







System procedures that change the master database or create 
temporary tables cannot be used inside user-defined transactions. 

Never use the following commands inside a user-defined 
transaction: 



Table 17-2: DDL commands not allowed in transactions 

alter database disk init load transaction select into 

alter table-partition dump database load database update statistics 

alter table...unpartition dump transaction reconfigure truncate table 

create database drop database 



You can check the current setting of ddl in tran with sp_helpdb. 

Beginning and Committing Transactions 

The begin transaction and commit transaction commands can enclose any 
number of SQL statements and stored procedures. The syntax for 
both statements is: 

begin {transaction | tran} [ trans action^name] 

commit {transaction | tran | work} [ transaction name] 

transaction_name is the name assigned to the transaction. It must 
conform to the rules for identifiers. 

The keywords transaction, tran, and work (in commit transaction) are 

synonymous; you can use one in the place of the others. However, 
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transaction and tran are Transact-SQL extensions; only work is SQL 
standards-compliant. 

Here is a skeletal example; 

begin tran 

b tat erne nt 

procedure 

statement 
commit tran 

commit transaction does not affect SQL Server if a transaction is not 
currently active. 



Rolling Back and Saving Transactions 

If a transaction must be canceled before it is committed — either 
because of some failure or because of a change by the user — all of its 
completed statements or procedures must be undone. 

You can cancel or roll back a transaction with the rollback transaction 
command at any time before the commit transaction command has been 
given. Using savepoints, you can cancel either an entire transaction 
or part of it. However, you cannot cancel a transaction after it has 
been committed. 

The syntax of the rollback transaction command is: 

rollback {transaction | tran | work} 
[ transaction name | savepoint_name] 

A savepoint is a marker that the user puts inside a transaction to 
indicate a point to which it can be rolled back. 

Savepoints are inserted by putting a save transaction command within 
the transaction. The syntax is: 

save {transaction | tran} savepoin t_name 

The savepoint name must conform to the rules for identifiers. 

If no savepoint_mme or transaction_name is given with the rollback 
transaction command, the transaction is rolled back to the first begin 
transaction in a batch. 

Here is how you can use the save transaction and rollback transaction 

commands: 
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begin tran transaction^name 

statement 

statement 

procedure 
save tran s avepoi nt_name 

sta temen t 
rollback tran savepointname 

statement 

statement 
rollback tran 

The first rollback transaction command rolls the transaction back to the 
savepoint inside the transaction. The second rollback transaction rolls 
the transaction back to its beginning. If a transaction is rolled back to 
a savepoint, it must still proceed to completion or else be canceled 
altogether. 

Until you issue a commit transaction, SQL Server considers all 
subsequent statements to be part of the transaction, unless it 
encounters another begin transaction statement. At that point, SQL 
Server considers all subsequent statements to be part of this new 
nested transaction. Nested transactions are described in the next 
section. 

rollback transaction or save transaction does not affect SQL Server and does 
not return an error message if a transaction is not currently active. 

Checking the State of Transactions 

The global variable @@transtate keeps track of the current state of a 
transaction, SQL Server determines what state to return by keeping 
track of any transaction changes after a statement executes. 
@@transtate may contain the following values: 



Table 17-3: @@transtate values 



Value 


Meaning 


0 


Transaction in progress. An explicit or implicit transaction is 




in effect; the previous statement executed successfully. 


1 


Transaction succeeded. The transaction completed and 




committed its changes, 


2 


Statement aborted. The previous statement was aborted; no 




effect on the transaction. 


3 


Transaction aborted. The transaction aborted and rolled 




back any changes. 
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In a transaction, you can use @@transtate after a statement (such as an 
insert) to determine whether it was successful or aborted, and to 
determine its effect on the transaction. The following example checks 
@@transtate during a transaction (after a successful insert) and after 
the transaction commits: 

begin transaction 

insert into publishers (pub_id) values ( ■ 9999 ■ ) 

(1 row affected) 
select @@transtate 

0 

(1 row affected) 
commit transaction 

select @@transtate 

1 

(1 row affected) 

This next example checks @@transtate after an unsuccessful insert 
(due to a rule violation) and after the transaction rolls back: 

begin transaction 

insert into publishers (pubid) values ('7777') 

Msg 552, Level 16, State 1: 

A column insert or update conflicts with a rule 
bound to the column. The command is aborted. The 
conflict occured in database , pubs2 r / table 
'publishers 1 , rule ' pub_idrule' , column r pub_id' . 

select @@transtate 

2 

(1 row affected) 
rollback transaction 
select @@transtate 
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3 

(1 row affected) 

Unlike @@error t however, SQL Server does not clear @@transtate after 
every statement. It changes @@transtate only in response to an action 
taken by a transaction. 

Nested Transactions 



You can nest transactions within other transactions. When you nest 
begin transaction and commit transaction statements, the outermost pair 
actually begin and commit the transaction. The inner pairs just keep 
track of the nesting level. SQL Server does not commit the 
transaction until the commit transaction that matches the outermost 
begin transaction is issued. 

SQL Server provides a global variable, @@trancount, that keeps track 
of the current nesting level for transactions. An initial implicit or 
explicit begin transaction sets @@>trancount to 1. Each subsequent begin 
transaction increments @@trancount and a commit transaction decrements 
it. Firing a trigger also increments @@trancount, and the transaction 
begins with the statement that causes the trigger to fire. Nested 
transactions are not committed until @@trancount equals 0. 

For example, the following nested groups of statements are not 
committed by SQL Server until the final commit transaction: 

begin tran 

select @@trancount 
/* @@trancount - 1 */ 

begin tran 

select @@trancount 
/* @@t ran count = 2 */ 

begin tran 

select @@trancount 

/* @@trancount ~ 3 */ 
commit tran 

commit tran 

commit tran 
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select @@trancount 

/* @@ trancount = 0 */ 

When you nest a rollback transaction statement without including a 
transaction or savepoint name, it always rolls back to the outermost 
begin transaction statement and cancels the transaction. 

Example of a User-Defined Transaction 

This example shows how a user-defined transaction might be 
specified: 

begin transaction royal ty_change 



/* A user sets out to change the royalty split */ 

/* for the two authors of The Gourmet Microwave. */ 

/* Since the database would be inconsistent */ 

/* between the two updates, they must be grouped */ 

/* into a transaction. */ 



update titleauthor 
set royal typer = 6 5 
from titleauthor, titles 
where royal typer - 7 5 

and titleauthor. title_id = titles . title_id 
and title = "The Gourmet Microwave" 



update titleauthor 
set royal typer = 3 5 
from titleauthor, titles 
where royal typer = 2 5 

and titleauthor . title_id = titles . title_id 
and title = "The Gourmet Microwave" 



save transaction percent_changed 



/* After updating the royaltyper entries for */ 

/* the two authors, the user inserts the */ 

/* savepoint w percent_changed, " and then checks */ 

/* to see how a 10 percent increase in the 

/* price would affect the authors' royalty */ 

/* earnings. */ 
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update titles 

set price ■ price * 1.1 

where title = "The Gourmet Microwave" 



select (price * royalty * total_sales) * royaltyper 

from titles, titleauthor, roysched 

where title s "The Gourmet Microwave" 

and titles . title_id - titleauthor . title_id 

and titles. title id ^roysched. title_id 

rollback transaction percent_changed 

/* The transaction rolls back: to the savepoint */ 
/* with the rollback transaction command. */ 
/* Without a savepoint, it would roll back to */ 
/* the begin transaction. */ 



commit transaction 



Selecting Transaction Mode and Isolation Level 

SQL Server provides two options you can set to support SQL 
standard-compliant transactions. These options define the 
transaction mode and transaction isolation level. You should set 
these options at the beginning of every session that requires SQL 
standards-compliant transactions. 

SQL Server supports the following transaction modes: 

• The default mode, called unchained or Trans act- SQL mode, 
requires explicit begin transaction statements paired with commit 
transaction or rollback transaction statements to complete the 
transaction. 

• The SQL standards-compatible mode, called chained mode, 
implicitly begins a transaction before any data retrieval or 
modification statement. These statements include: delete, insert, 
open, fetch, select, and update. You must still explicitly end the 
transaction with commit transaction or rollback transaction. 

You can set either mode using the chained option of the set command. 
However, you should not mix these transaction modes in your 
applications. The behavior of stored procedures and triggers can 
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vary depending on the mode, and you may require special action to 
run a procedure in one mode that was created in the other. 

SQL Server supports the following transaction isolation levels: 

• Level 0 - SQL Server ensures that data written by one transaction 
represents the actual data. This level prevents other transactions 
from writing over the same data until the transaction commits. 
The other transactions can still read the uncommitted data. 

• Level 1 - SQL Server ensures that data read by one transaction 
represents the actual data, not the data in the process of another 
uncommitted transaction. This is the default isolation level 
supported by SQL Server. 

• Level 3 - SQL Server ensures that data read by one transaction is 
valid until the end of that transaction. It supports this level 
through the holdlock keyword of the select statement which applies 
a read-lock on the specified data. 

You can set the isolation level for your session using the transaction 
isolation level option of the set command. You can enforce the isolation 
level for just a query as opposed to using the at isolation clause of the 
select statement. 

The following sections describe these options in more detail. 

Choosing a Transaction Mode 

The SQL standards require every SQL data- retrieval and data- 
modification statement to occur inside of a transaction. A transaction 
automatically starts with the first data-retrieval or data-modification 
statement after the start of a session or after the previous transaction 
commits or aborts. This is the chained transaction mode. 

You can set this mode for your current session by turning on the 
chained option of the set statement. For example; 

set chained on 

However, you cannot execute the set chained command within a 
transaction. To return to the unchained transaction mode, set the 
chained option off The default transaction mode is unchained. 

In the chained transaction mode, SQL Server implicitly executes a 
begin transaction statement just before the following data retrieval or 
modification statements: delete, insert, open, fetch, select, and update. For 

example, the following group of statements produce different results 
depending on which mode you use: 
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insert into publishers 

values C9999', null, null, null) 
begin transaction 

delete from publishers where pub_id = *9999' 
rollback transaction 

In unchained mode, the rollback affects only the delete statement, so 
publishers still contains the inserted row. In chained mode, the insert 
statement implicitly begins a transaction, and the rollback affects all 
statements up to the beginning of that transaction, including the 
insert. 

Although chained mode implicitly begins transactions with data 
retrieval or modification statements, you can nest transactions only 
by explicitly using begin transaction statements. Once the first 
transaction implicitly begins, further data retrieval or modification 
statements no longer begin transactions until after the first 
transaction commits or aborts. For example, in the following query, 
the first commit transaction commits all changes in chained mode; the 
second commit is unnecessary: 

insert into publishers 

values (»9999', null, null, null) 

insert into publishers 

values ('9997', null, null, null) 

commit transaction 
commit transaction 



In chained mode, a data retrieval or modification statement begins a 
transaction whether or not it executes successfully. Even a select that does 
not access a table begins a transaction. 



You can check the global variable @@tranchained\o determine SQL 
Server's current transaction mode, select @@tranchained returns a 0 for 
unchained mode or a 1 for chained mode. 

Choosing an Isolation Level 

The SQL92 standard defines four levels of isolation for transactions. 
Each isolation level specifies the kinds of actions that are not 
permitted while concurrent transactions are executing. Higher levels 
include the restrictions imposed by the lower levels: 
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• Level 0 prevents other transactions from changing data that has 
already been modified (through an insert, delete, update, and so on) 
by an uncommitted transaction. The other transactions are 
blocked from modifying that data until the transaction commits. 
However, other transactions can still read the uncommitted data, 
which results in dirty reads. 

• Level 1 prevents dirty reads. Such reads occur when one 
transaction modifies a row, and then a second transaction reads 
that row before the first transaction commits the change. If the 
first transaction rolls back the change, the information read by the 
second transaction becomes invalid. 

• Level 2 prevents nonrepeatable reads. Such reads occur when 
one transaction reads a row and a second transaction modifies 
that row. If the second transaction commits its change, 
subsequent reads by the first transaction yield different results 
than the original read. 

• Level 3 prevents phantoms. Phantoms occur when one 
transaction reads a set of rows that satisfy a search condition, and 
then a second transaction modifies the data (through an insert, 
delete, update, and so on). If the first transaction repeats the read 
with the same search conditions, it obtains a different set of rows. 

By default, SQL Server's transaction isolation level is 1. The SQL92 
standard requires that level 3 be the default isolation for all 
transactions. This prevents dirty reads, nonrepeatable reads, and 
phantoms. To enforce this default level of isolation, Transact-SQL 
provides the transaction isolation level 3 option of the set statement. This 
option instructs SQL Server to automatically apply a holdlock to all 
select operations in a transaction. For example: 

set transaction isolation level 3 

Applications that use transaction isolation level 3 should set that isolation 
level at the beginning of each session. However, setting transaction 
isolation level 3 causes SQL Server to hold any read-locks for the 
duration of the transaction. If you also use the chained transaction 
mode, that isolation level remains in effect for any data retrieval or 
modification statement that implicitly begins a transaction. In both 
cases, this can lead to concurrency problems for some applications, 
since more locks may be held for longer periods of time. 

To return your session to the SQL Server default isolation level: 

set transaction isolation level 1 

Applications that are not impacted by dirty reads may see better 
concurrency and reduced deadlocks when accessing the same data 
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by setting transaction isolation level 0 at the beginning of each session. An 
example is an application that finds the momentary average balance 
for all savings accounts stored in a table. Since it requires only a 
snapshot of the current average balance, which probably changes 
frequently in an active table, the application should query the table 
using isolation level 0, Other applications that require data 
consistency such as deposits and withdrawals to specific accounts in 
the table, should avoid using isolation level 0, 

Queries executing at isolation level 0 do not acquire any read locks 
for their scans, so they do not block other transactions from writing 
to the same data, and vice versa. However, even if you set your 
isolation level to 0, utilities (like dbcc) and data modification 
statements (like update) still acquire read locks for their scans, because 
they must maintain the database integrity by ensuring that the 
correct data has been read before modifying it. 

The global variable @@isolation contains the current isolation level of 
your Transact-SQL session. Querying @@>isolation returns the value 
of the active level (0 f 1, or 3). For example: 

select ©©isolation 



1 

(1 row affected) 

For more information about isolation levels and locking, see the 
Performance and Tuning Guide. 

Changing the Isolation Level for a Query 

You can change the isolation level for a query by using the at isolation 
clause with the select or readtext statements. The read uncommitted, read 
committed, and serializable options of at isolation represent each isolation 
level as defined below: 



at isolation Option 


Isolation Level 


read uncommited 


0 


read committed 


1 


serializable 


3 



For example, the following two statements query the same table at 
isolation levels 0 and 3, respectively: 
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select * 
from titles 

at isolation read uncommitted 

select * 
from titles 

at isolation serializable 

The at isolation clause is valid only for single select and readtext queries 
or in the declare cursor statement. SQL Server returns a syntax error if 
you use at isolation as follows: 

• With a query using the into clause 

• Within a subquery 

• With a query in the create view statement 

• With a query in the insert statement 

• With a query using the for browse clause 

If there is a union operator in the query, you must specify the at isolation 
clause after the last select. 

The SQL92 standard defines read uncommitted, read committed, and 
serializable as options for at isolation (and set transaction isolation level as 

well). A Transact-SQL extension also allows you to specify 0, 1, or 3 
for at isolation. To simplify the discussion of isolation levels, the 
at isolation examples in this manual do not use this extension. 

You can also enforce isolation level 3 using the holdlock keyword of 
the select statement. However, you cannot specify holdlock, noholdlock, 
or shared in a query that also specifies at isolation read uncommitted. When 
you use different ways to set an isolation level, the holdlock keyword 
takes precedence over the at isolation clause (except for isolation level 
0), and at isolation takes precedence over the session level defined by 
set transaction isolation level. 



Cursors and Isolation Levels 



You can use the select statement's at isolation clause to change the 
isolation level with a cursor. For example: 

declare commi t_crs r cursor 
for select * 
from titles 

at isolation read committed 

This statement makes the cursor operate at isolation level 1, 
regardless of the isolation level of the transaction or session. If you 
declare a cursor at isolation level 0 (read uncommitted) , SQL Server also 
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defines the cursor as read-only. You cannot specify the for update 
clause along with at isolation read uncommitted in a declare cursor 

statement. 

SQL Server decides a cursor's isolation level when you open it, not 
when it is declared. Once you open the cursor, SQL Server 
determines its isolation level based on the following: 

• If the cursor was declared with the at isolation clause, that isolation 
level overrides the transaction isolation level in which it is 
opened. 

• If the cursor was not declared with at isolation, the cursor uses the 
isolation level in which it is opened. If you close the cursor and 
reopen it later, the cursor acquires the current isolation level of 
the transaction. 

The caveat to the last point is that certain types of cursors (language 
and client) declared in a transaction with isolation level 1 or 3 cannot 
be opened in a transaction with isolation level 0. For more 
information about this restriction and about the different types of 
cursors, see the SQL Server Reference Manual 

Stored Procedures and Isolation Levels 



The Sybase system-stored procedures always operate at isolation 
level 1, regardless of the transaction or session isolation level. User 
stored procedures operate at the isolation level of the transaction that 
executes it. If the isolation level changes within a stored procedure, 
the new isolation level remains in effect only during the execution of 
the stored procedure. 

Triggers and Isolation Levels 

Since triggers are fired by data modification statements (like insert), 
all triggers execute at either the transaction's isolation level or 
isolation level 1 , whichever is higher. So, if a trigger fires in a 
transaction at level 0, SQL Server sets the trigger's isolation level to 1 
before executing its first statement. 
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Using Transactions in Stored Procedures and Triggers 

You can use transactions in stored procedures and triggers just as 
with statement batches. If a transaction in a batch or stored 
procedure invokes another stored procedure or trigger containing a 
transaction, that second transaction is nested into the first one. 

The first explicit or implicit (using chained mode) begin transaction 
starts the transaction in the batch, stored procedure, or trigger. Each 
subsequent begin transaction increments the nesting level. Each 
subsequent commit transaction decrements the nesting level until it 
reaches 0. SQL Server then commits the entire transaction. A rollback 
transaction aborts the entire transaction up to the first begin transaction 
regardless of the nesting level or the number of stored procedures 
and triggers it spans. 

In stored procedures and triggers, the number of begin transaction 
statements must match the number of commit transaction statements. 
This also applies to stored procedures that use chained mode. The 
first statement that implicitly begins a transaction must also have a 
matching commit transaction. 

The following illustration demonstrates what can happen when you 
nest transaction statements within stored procedures; 
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batch 



begin tran 

statements... 

exec myproc 
if ... rollback tran 
else commit tran 



® 



transaction started 
by begin tran 



myproc 



create proc myproc 
as 

begin tran 
statements... 
exec nextproc 
if .„ rollback tran 
else commit tran 



® begin tran increments 
nesting level 



nextproc 



create proc nextproc 
as 

begin tran 

statements.,, 
if... rollback tran 
else commit tran 



© begin tran increments 
nesting level 



© rollback aborts all 
statements in 
myproc, nextproc, 
and batch 
-or- 

commit commits all 
statements in 
myproc, nextproc, 
and batch 



Figure 17-1: Nesting transaction statements 

rollback transaction statements in stored procedures do not affect 
subsequent statements in the procedure or batch that originally 
called the procedure. SQL Server executes subsequent statements in 
the stored procedure or batch. However, rollback transaction statements 
in triggers do abort the batch so that subsequent statements are not 
executed. 

For example, the following batch calls the stored procedure myproc 
which includes a rollback transaction statement: 



© commit decrements 
nesting level 
-or- 

rollback aborts all 
statements in 
myproc, nextproc 
and batch 



© commit decrements 
nesting level 
-or- 

roliback aborts all 
statements in 
myproc, nextproc 
and batch 



17-18 



Transactions: Maintaining Data Consistency and Recovery 



Sybase SQL Server Release 11.0.x 



Using Transactions in Stored Procedures and Triggers 



begin tran 

update titles set . . . 
insert into titles . . . 
execute myproc 
delete titles where . . . 

The update and insert statements are rolled back and the transaction is 
aborted. SQL Server continues the batch and executes the delete 
statement. However, if there is an insert trigger on a table that 
includes a rollback transaction, the entire batch is aborted and the delete 

is not executed. For example: 

begin tran 

update authors set . . . 
insert into authors . . . 
delete authors where . . . 

Different transaction modes or isolation levels for stored procedures 
have certain requirements, which are described in the next section. 
Triggers are not affected by the current transaction mode since they 
are always called as part of a data modification statement. 



Transaction Modes and Stored Procedures 



Stored procedures written to use the unchained transaction mode 
may be incompatible with other transactions using chained mode, 
and vice versa. For example, following is a valid stored procedure 
using chained transaction mode: 

create proc myproc 
as 

insert into publishers 

values < , 9999', null, null, null) 
commit work 

A program using unchained transaction mode would fail if it called 
this procedure because the commit does not have a corresponding 
begin. You may encounter other problems: 

• Applications that start a transaction using chained mode may 
create impossibly long transactions, or may hold data locks for 
the entire length of their session. This behavior degrades SQL 
Server performance. 

• Applications may nest transactions at unexpected times. This can 
produce different results depending on the transaction mode. 

As a rule, applications using one transaction mode should call stored 
procedures written to use that same mode. The exceptions to that 
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rule are Sybase system-stored procedures (not including 
sp_procxmode, described below), which can be invoked by sessions 
using any transaction mode. If no transaction is active when you 
execute a system-stored procedure, SQL Server turns off chained 
mode for the duration of the procedure. Before returning, it resets the 
mode its original setting. 

SQL Server tags all procedures with the transaction mode ("chained" 
or "unchained") of the session in which they are created. This helps 
avoid problems associated with transactions using one mode 
invoking other transactions using the other mode. A stored 
procedure tagged as "chained" is not executable in sessions using 
unchained transaction mode, and vice versa. 

♦ WARNING! — ^— ^ ' > 

When using transaction modes, be aware of the effects each setting 

can have on your applications. 



Setting Transaction Modes for Stored Procedures 

You can use the sp_procxmode system stored procedure to change the 
tag value associated with a stored procedure. SQL Server also 
provides a third tag, "anymode", which you can use with 
sp_procxmode to indicate stored procedures that can run under either 
transaction mode. For example: 

sp_procxmode byroyalty, "anymode" 

Use sp_procxmode without any parameter values to get the transaction 
modes for all stored procedures in the current database: 



sp_p r o cxmode 

procedure name 



byroyalty 

discount_proc 

insert_sales_proc 

insert_salesdetai l_proc 

storeid_proc 

s torename_proc 

title_proc 

titleid_proc 



transaction mode 

Unchained 
Unchained 
Unchained 
Unchained 
Unchained 
Unchained 
Unchained 
Unchained 



(8 rows affected, return status 



0) 
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You can use sp_procxmode only in unchained transaction mode. 

To change a procedure's transaction mode, you must be a System 
Administrator, the Database Owner, or the owner of the procedure. 

Using Cursors in Transactions 



By default, SQL Server does not change a cursor's state (open or 
closed) when a transaction ends through a commit or roll back. The 
SQL standards, however, associate an open cursor with its active 
transaction. Committing or rolling back that transaction 
automatically closes any open cursors associated with it. 

To enforce this SQL standards-compliant behavior, SQL Server 
provides the close on endtran option of the set command. In addition, if 
you set chained mode on, SQL Server starts a transaction when you 
open a cursor, and it closes that cursor when the transaction is 
committed or rolled back. 

For example, the following sequence of statements produces an error 
by default: 

open cursor test 
commit tran 
open cursor test 

If you set either the close on endtran or chained options, the cursor's state 
changes from open to closed after the commit. This allows the cursor 
to be reopened. 

Any exclusive locks acquired by a cursor in a transaction are held 
until the end of that transaction. This also applies to shared locks 
when using the holdlock keyword, the at isolation serializable clause, or 
the set isolation level 3 option. However, if you do not set the close on 
endtran option, the cursor remains open past the end of the 
transaction, and its current page lock remains in effect. It could also 
continue to acquire locks as it fetches additional rows. 

Backup and Recovery of Transactions 



Every change to the database, whether it is the result of a single update 
statement or a grouped set of SQL statements, is automatically 
recorded in the system table syslogs. This table is called the 
transaction log. 
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Some commands that change the database are not logged, such as 
truncate table, bulk copy into a table that has no indexes, select into, 
writetext and dump transaction with nojog. 

The transaction log records update, insert, or delete statements on a 
moment-to-moment basis. When a transaction begins, a begin 
transaction event is recorded in the log. As each data modification 
statement is received, it is recorded in the log. 

The change is always recorded in the log before any change is made 
in the database itself. This type of log, called a write-ahead log, 
ensures that the database can be recovered completely in case of a 
failure. 

Failures can be due to hardware or media problems, system software 
problems, application software problems, program-directed 
cancellations of transactions, or user decisions to cancel a 
transaction. 

In case of any of these failures, the transaction log can be played back 
against a copy of the database restored from a backup made with the 
dump commands. 

To recover from a failure, transactions that were in progress but not 
yet committed at the time of the failure must be undone, because a 
partial transaction is not an accurate change. Completed transactions 
must be redone if there is no guarantee that they have been written 
to the database device. 

If there are active, long-running transactions that are not committed 
when SQL Server fails, undoing the changes may require as much 
time as the transaction has been running. Such cases include 
transactions that do not contain a commit transaction or rollback transaction 
to match a begin transaction. This prevents SQL Server from writing 
any changes and increases recovery time. 

SQL Server's dynamic dump allows the database and transaction log 
to be backed up while use of the database continues. Make frequent 
backups of your database transaction log. The more often you back 
up your data, the less work will be lost if a system failure occurs. 

The owner of each database or a user with OPER authorization is 
responsible for backing up the database and its transaction log with 
the dump commands, though permission to execute them can be 
transferred to other users. Permission to use the load commands, 
however, defaults to the Database Owner and cannot be transferred. 

Once the appropriate load commands are issued, SQL Server handles 
all aspects of the recovery process. SQL Server also automatically 
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controls the checkpoint interval, which is the point at which all data 
pages that have been changed are guaranteed to have been written to 
the database device. Users can force a checkpoint if necessary with 
the checkpoint command. 

For more information, see the SQL Server Reference Manual and the 
System Administration Guide, 
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